In constrained computing environments, such as set-top boxes, self-contained mini-applications provide effective means for supporting user interaction. These self-contained mini-applications are sometimes referred to as “widgets.” Widgets have been implemented in a variety of different ways including as compiled source code targeted to run in particular end-user hardware and software environments. Widgets have also been implemented as source code that is compiled into bytecode and then run on a platform-specific virtual machine which makes appropriate use of the platform's middleware, operating system, and other resources. Widgets have also been implemented as Enhanced TV Binary Interchange Format 1.0 (EBIF) applications.
To speed deployment, reduce costs, and improve reliability, application template customization approaches can be used for widget implementation. These approaches are generally oriented toward reducing the need to create and test new code by reusing components and parameterizing common functions. Skinning, which generally refers to the ability to personalize application Graphic User Interfaces (GUIs) by separating presentation details from the underlying data, has deployment, cost, and reliability benefits. Skinning accomplishes this by providing multiple platform-specific GUIs while leveraging some common components. Well known examples of skinning include those implemented in most instant messaging clients, media players, and web browsers like Mozilla and Opera. In the interactive TV (iTV) domain, use of templates and skinning are disclosed in U.S. Pat. Nos. 7,231,630 and 7,430,718.
Any approach that generates customized source code, even code based on common, reused source modules, can cause problems when not properly created and tested to function with end-user environments. In cable TV systems, for example, a given widget will likely be deployed simultaneously to a large number of heterogeneous digital cable systems across the country. A single misspelling or excessively long text string introduced during template customization can produce serious errors. An extraneous byte in a popular application's measurement response can cause a system's return-path network to fail. To provide acceptable reliability, a conventional application template customization approach may require testing for every application variation created from a template. At least one full operator system trial may also be required to uncover any bandwidth or timing induced problems. This approach would be prohibitively expensive and rule out rapid sales-customization-deployment-response cycles. It would therefore be desirable to have a way to reduce defects in customized templates.